IBIS Macromodel Task Group Meeting date: 14 April 2020 Members (asterisk for those attending): Achronix Semiconductor * Hansel Dsilva ANSYS: Curtis Clark Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Ken Willis * Jared James Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan Todd Bermensolo Stephen Slater Marvell Steve Parker Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Justin Butterfield took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Walter to send his "BIRD_DQ_DQS_Clocking" presentation and BIRD draft to the ATM list. - Arpad reported this was done. - Arpad to ask Steve Parker to post Walter's documents to the ATM work archives. - Arpad is still waiting on this. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the April 7 meeting. Randy moved to approve the minutes. Ambrish seconded the motion. There were no objections. ------------- New Discussion: DDR Clock Forwarding: Fangyi shared his comments on the DDR Clock Forwarding BIRD draft that he sent over email. He asked if we really need the Times input mode. Ambrish replied we need the Times input types. If the EDA tool can provide the clock_times, this can reduce the burden on the model maker. He noted this can be a simpler approach, and the model maker can decide the input type of clock_times. Arpad noted this parameter tells what is stored in the memory location for clock_times. Ambrish commented the models he has would be sufficient to use the Times type. Fangyi noted the DQS model might have its own way of computing the Times information. Regarding the requirement to have None in the list, Fangyi commented this would require every model to support having its own CDR. Walter stated we can let the market decide how this should be done. He suggested it would be a good practice for model makers to support the None option with no explicit clock_times input. Ambrish asked if this would require the EDA tool to support the external clock_times. Arpad asked if this parameter is an input to model. Walter replied, yes, the Rx_Use_Clock_Input parameter tells the model which mode you are in. Fangyi commented it is both telling the EDA tool what to do and an input to the model. Walter commented we have other Reserved Parameters that are similar concepts. Arpad asked, since the EDA tool will ask the user to pick one of these options, is this a question for the model and not the user. Fangyi replied the user may or may not care about the jitter tracking. Ambrish asked, if the model can determine from the data, what type of input it has. Fangyi replied the model needs to know how to interpret the clock_times pointer. Arpad asked if this is a parameter for the DQ or the DQS model. Fangyi replied it is for the DQ. Randy asked if the Other Notes applies to Times and Wave. Fangyi agreed we should clarify the last sentence. Ambrish commented the EDA tool will process the DQS waveform regardless of the DLL. The concern is if the DLL is not there the EDA tool can handle this. Randy commented, regarding the None option, he plans to continue to have a CDR in the model to support the case where a user wants to run a simple simulation. Fangyi asked if all models should support the None option. Randy agreed it might not be required. We could remove the requirement and let the market decide, as Walter previously stated. Bob asked if omitting the parameter is the same as None. Radek stated the parameter allows the user to select the option mode they want to simulate. Randy suggested the parameter can be omitted if it is not supported. Ambrish commented, to be able to use this model in EDA tools supporting only older versions of IBIS, None will be required for the model. Randy agreed, if you have a model that supports None, it can work in older tools. Bob asked if we are supporting both Usage In and Usage Info. Arpad replied we are effectively doing both, but for other similar parameters we have them as Usage In. Fangyi stated any parameter that is listed is also Info. Arpad noted the parameter Modulation is "Usage In, Info". He suggested to make this parameter Usage In and make a statement that the EDA tool will use the parameter. Ambrish suggested it should be "Usage In and Info" and to clarify this in the text. Bob noted the syntax does not support "Usage In and Info". Arpad agreed and suggested in the rules we can say the tool will use the parameter. Fangyi agreed and made the parameter Usage In and added a sentence about this in the Usage Rules section. Arpad shared the DLL_Path parameter from IBIS 7.0, which is Usage In. It has text stating what the EDA tool is responsible for. Fangyi agreed this is more clear. Radek asked if any combination of the None, Times, and Wave parameter values makes sense. He suggested only having None would not make much sense. Randy asked if Value should be listed as a valid Format. Arpad agreed Value would make sense as a Format. He commented we need to decide if we are requiring the None option to be present to answer Radek's question. Randy asked if the List can accept one value. Bob noted we have defined strings for the parameter options in the past. Arpad commented, for List, we do not have any requirement in the IBIS specification that it has more than one value, but he was not sure about the parser. Fangyi changed the Format to "List, Value". Fangyi noted he fixed a few typos. He also changed the phrase "Rx DQ" to "DQ Rx". Fangyi asked if we are passing the contents or the pointer. Arpad asked if it will waste memory to copy the contents. Ambrish agreed we want to pass the pointer. Fangyi asked about the definition of the issue where it mentions the x4 and x8 DQ cases. Randy stated these cases would be possible. Arpad asked if we should change "DLL" to "executable model". Fangyi made this change. Michael asked if there is a requirement for the DQS to have an executable model. Fangyi asked if it was clear from the Other Notes text. Michael noted it is a question of abstraction, where the analog model data would be supported by model or by the EDA tool. It is not clear if the DQS AMI model is required. Michael asked if this is something we should clarify. Fangyi replied this is outside the scope of this BIRD. Walter stated if the DQS DLL is required the model the maker should provide one. If the DQS model is supplied, then it should be used by the EDA tool. Arpad suggested we should add a sentence about this to the BIRD. - Ambrish: Motion to adjourn. - Randy: Second. - Arpad: Thank you all for joining. AR: Fangyi to send out the updated version of the BIRD_DQ_DQS_Clocking. AR: Arpad to ask Steve Parker to post Fangyi's document to the ATM work archives. ------------- Next meeting: 21 April 2020 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives